As part of the Training Sessions initiative organized by the Debian Women project, this Thursday we will hold a lesson on how to use the Debian Bug Tracking System.

Like the previous sessions, this lesson will take place on #debian-women on irc.debian.org, at 19:00 UTC on Thursday 9th December.

Logs will be available immediately after the lesson at the usual place and a wiki tutorial will be created a few days later. You might want to follow our group on identi.ca for further information!

See you on Thursday!

Contributed by: Francesca Ciceri

On the 25th of November I held a training session for the Debian Women project, about Using Git. A transcript of the session is available. The session took 2,5 hours, more than I really expected (one hour less), but I had many questions asked. There were ~160 attendants, but many of those asking questions seem to have missed that this was a "basic" session, for people who never used it. All in all, it was a great experience. While preparing the talk, I had the chance to re-read some forgotten manpages, which clarified some points, so it was really useful for me as well Given the kind of questions I had, it would be nice to have an "Advanced Git" session, maybe in January-February. Any volunteers? I'll sure be attending it FYI, the next session will be held by POX (Piotr O arowski) next Thursday (Dec, 2). It will be about Python libraries/application packaging, you'll have to read the introductory session as a pre-requisite.

The Debian Women project is pleased to announce the -start of a series of training sessions to be held via IRC in the Debian Women IRC channel, #debian-women on irc.debian.org

The first session has been scheduled for Thursday, 18th November at 20:00 UTC. Lars Wirzenius, will give an introductory lesson titled Introduction to Debian Packaging .

The main goal of this initiative is to encourage more people, specifically women, to contribute to Debian while introducing them to different aspects of the Debian Project. Topics will span a wide range of subjects related to daily Debian maintenance efforts as well as advanced tasks and are open to everybody, regardless of gender or previous involvements in the community.

Future sessions will be held on a regular basis, and will cover collaborative maintenance with git, Python modules and applications packaging, and many more. Please visit the Training Sessions wiki page regularly to check the up-to-date agenda and follow our group on identi.ca. You may also refer to the wiki to suggest new topics or sign up yourself as a trainer: we are always looking for more people to share knowledge and complete the schedule, so don t be shy!

For further information about the Debian Women project, please visit the Debian-Women website or send mail to the Debian Women mailing list.

The Debian Women project aims to get more women to participate in Debian, as packagers, bug reporters, technical documentation writers, bug fixers, translators, artists and in any other area that helps the development of Debian. These goals are achieved through IRC tutorials, a mentoring program, a mailing list and an IRC channel.

The Mentoring Program, allows men and women that want to contribute to Debian but aren t sure where or how to start, to get some help with their first steps.

There have been at least 38 women that have contributed in packaging software for Debian, and there are currently 11 female Debian Developers and 1 Debian Maintainer. We d like to raise those numbers to 50 packagers by the end of 2011, and 20 Debian Developers by the end of 2012.

There are some other interesting statistics about the current female participation in Debian.

We are also interested in getting more women to file and fix bugs, translate debconf templates or package descriptions, contribute to the release notes, as well as participate in any other areas of the Debian project. In order to do this, we will be holding some IRC training sessions in the near future, to help people get started. We are currently making the list of subjects and trainers, we ll publish more news about this once the first sessions are scheduled.

For more information you can join the IRC channel #debian-women on irc.oftc.net, or subscribe to the debian-women mailing list. If you are a Spanish speaker, you can also join the IRC channel #debian-mujeres on irc.oftc.net.

Contributed by: Margarita Manterola

In a previous post I mentioned split debugging info. One addendum to this is how symbols are handled. Symbols are separate to debugging info (i.e. the stuff about variable names, types, etc you get when -g is turned on), but necessary for a good debugging experience. You have a choice, however, of where you leave the symbol files. You can leave them in your shipping binary/library so that users who don't have the full debugging info available will still get a back-trace that at least has function names. The cost is slightly larger files for everyone, even if the symbols are never used. This appears to be what Redhat does with it's system libraries, for example. The other option is to keep the symbols in the .debug files along-side the debug info. This results in smaller libraries, but really requires you to have the debug info files available to have workable debugging. This appears to be what Debian does. So, how do you go about this? Well, it depends on what tools you're using. For binutils strip, there is some asynchronicity between the --strip-debug and --only-keep-debug options. --strip-debug will keep the symbol table in the binary, and --only-keep-debug will also keep the symbol table. Of course, you can then strip (with no arguments) the final binary to get rid of the symbol table; but other than manually pulling out the .symtab section with objcopy I'm not aware of any way to remove it from the debug info file. Constrast with elfutils; more commonly used on Redhat based system I think. eu-strip's --strip-debug does the same thing; leaves the symtab section in the binary. However, it also has a -f option, which puts any removed sections during the strip into a separate file. Therefore, you can create any combination you wish; eu-strip -f results in an empty binary with symbols and debug data in the .debug file, while eu-strip -g -f results in debug data only in the .debug file, and symbol data retained in the binary. The only thing to be careful about is using eu-strip -g -f and then further stripping the binary, and consequently destroying the symbol table, but retaining debug info. This can lead to some strange things in backtraces: Note one difference between strip and eu-strip is that binutils strip will leave the .gnu_debuglink section in, while eu-strip will not:

Tip: if you would like your own cow sticker, take a cute child through the checkouts at your local Whole Foods.

Some time ago I wrote a description of the -Bsymbolic linker flag which could do with some further explanation. The original article is a good starting place. One interesting point that I didn't go into was the potential for code optimisation -Bsymbolic brings about. I'm not sure if I missed that at the time, or the toolchain changed, both are probably equally likely! Let me recap the example... In words; libtest.so provides test_foo(), which calls foo() to do the actual work. libtest-bsymbolic.so is simply built with the flag in question, -Bsymbolic. liboverride.so provides the alternative version of foo() designed to override the original via a LD_PRELOAD of the library. test is built against libtest.so, test-bsymbolic against libtest-bsymbolic.so. Running the examples, we can see that the LD_PRELOAD does not override the symbol in the library built with -Bsymbolic. There are a couple of things going on here. Firstly, you can see that the SYMBOLIC flag is set in the dynamic section, leading to the dynamic linker behaviour I explained in the original article: However, there is also an effect on generated code. Have a look at the PLTs: Notice the difference? There is no PLT entry for foo() when -Bsymbolic is used. Effectively, the toolchain has noticed that foo() can never be overridden and optimised out the PLT call for it. This is analogous to using "hidden" attributes for symbols, which I have detailed in another article on symbol visiblity attributes (which also goes into PLT's, if the above meant nothing to you). So -Bsymbolic does have some more side-effects than just setting a flag to tell the dynamic linker about binding rules -- it can actually result in optimised code. However, I'm still struggling to find good use-cases for -Bsymbolic that can't be better done with Version scripts and visibility attributes. I would certainly recommend using these methods if at all possible. Thanks to Ryan Lortie for comments on the original article.

I finally got a few hours free this morning to check an item off my home system administration checklist: upgrading the wireless router's firmware to OpenWRT. There were a couple motivations for this, including the fact that my SoundBridge Radio couldn't maintain a connection to my firefly server using the built-in firmware, and I had read that OpenWRT would work better. Since this is posted on Planet Debian, I should mention why I didn't use DebianWRT. The basic answer is this text at the top of the DebianWRT homepage:

Currently the most common methods used to run Debian on these systems is to install OpenWRT or a similar firmware, add disk space either by USB storage or NFS, create a debian chroot by either running cdebootstrap from inside OpenWRT or debootstrap --foreign on a PC, and running Debian from this chroot. For example, instructions for the WLHDD.

I'm not sure whether this is because DebianWRT is experimental, or because its goal is to use routers as cheap general computers. Either way, it sounds way too complicated and/or fragile for what I'm interested in (i.e., a wireless router with better software). The goal here is to get something that does a better job than the built-in WRT firmware, but doesn't require too much tinkering to get working or to maintain. I have plenty of outlets for my tinkering urges already. Nothing here was exactly difficult, but it was hard to find all the information I needed to get things working. Hopefully documenting the steps I went through here will save someone else some time. Step 1: acquire the firmware This was trickier than you might think. If you click on the download link at the OpenWRT web site, you end up at the top of an FTP server populated with a vast quantity of stuff. Worse, when you find the actual firmware images, you'll quickly discover that there are piles and piles of them divided between sixteen directories, and no guidance as to which one to pick. And picking the wrong one will turn your beautiful router into a doorstop. Luckily, the OpenWRT documentation contains a section called "Getting Started". Unluckily, that section consists of the following text:

1.1 Getting started 1.1.1 Installation 1.1.2 Initial configuration 1.1.3 Failsafe mode

Whoops, someone forgot to execute on a TODO. Undeterred, I consulted the usual fallback reference, Google. It pointed me at several references, some of which were hidden on other parts of the OpenWRT site. Armed with these, I was able to determine that:

1. My WRT54GL v1.1 probably uses a Broadcom 5352 chipset.
2. The correct firmware, according to multiple sources, is probably in the kamikaze top-level director, the latest version's subdirectory, and the bcrm-2.4 directory under the version (the link is to 8.09.2, which is current as of March 6, 2010). Apparently the bcrm47xx directory doesn't have wireless support; it helpfully contains a file called NO-BROADCOM-WIRELESS to warn you off, but unhelpfully doesn't include any additional information in that file (like what exactly is broken or that you can find a working firmware in a sibling directory) ... oh well.
3. The firmware file that you want is openwrt-wrt54g-squashfs.bin, even though it doesn't match the model number of the router. This directory could use a README file explaining which hardware is supported by each of the dozen or so firmware files it contains.

Step 2: install the firmware After Step 1, this was a real relief. I just used the built-in Linksys firmware installer, pointed it at the .bin file, and it went. Step 3: configure the router The installation guide I followed was pretty much silent about what to do after I got the firmware on. Luckily, this is just a software problem, meaning it's much more familiar territory for me.

1. First things first: I checked that I could still get a DHCP lease. It worked.
2. Armed with that, I tried telneting to the router. I used the resulting root prompt to set a password on the root account.
3. I logged out and tried telneting in. Apparently the router is configured to disallow root logins over telnet if you don't have a password. Good for them (although why allow telnet at all?); oops for me.
4. Luckily, an ssh server was installed by default. I like using keys to log in, so I tracked down the documentation on configuring the server to use public-key authentication; it turns out there's a single global key file named /etc/dropbear/authorized_keys that's exactly like OpenSSH's per-user authorized_keys file. No idea what would happen if I had multiple users, but I won't.
5. The next obstacle: I didn't have an Internet connection. For some reason, my cable modem didn't want to give the router a DHCP lease. On the off-chance that it was remembering too much, I rebooted it and ran ifup wan. That fixed the problem. I still don't know why.
6. Not a step, but a useful note: in the process of figuring the above out, I found readlog. It's basically dmesg for syslog files; it shows the most recent lines written to syslog. This is useful because there isn't a real syslog file, due to the fact that there would be no room to store it on the 54GL.
7. Finally, I had to get wireless working. The documentation is very helpful when it comes to describing the syntax of the wireless configuration. Unfortunately, I read the list of encryption options and missed the section right below where their meanings are explained (although, to be honest, I might not have understood the implications of the explanation without the research I did anyway).

   option encryption none, wep, psk, psk2, wpa, wpa2

   I wanted WPA2 encryption, so I entered wpa2. And nothing worked. After a good hour of trying different options on the client, swapping software components in and out on the router, experimenting with the encryption key syntax, and crawling Google, I finally found my answer. If you just want WPA2 encryption, you must not use wpa2 as the encryption type. Instead, use psk2. It turns out out that wpa2 actually means use WPA2 and also use an external RADIUS server for authentication. psk2 is the system you're familiar with from a typical consumer wireless router.

Step 4: enjoy And with that, it works. Unfortunately, contrary to what I wrote here originally, my Roku still doesn't work. On the other hand, having a real Linux installation is helpful for debugging it. Currently my suspicion is that the router isn't passing multicast packets between the wired and wireless interfaces (broadcast works fine, multicast doesn't). That said, it seems like if I restart Firefly just before I start playing music, I can play reasonably reliably -- as long as I don't stop, because if I do, the Roku forgets that the music server is there. Either way, I've spent about as much time fighting this as I can afford. One lingering worry I have is security; unlike Debian, which has both a security mailing list and tools to inform me when I need to install a security update, the OpenWRT firmware doesn't seem to have any mechanism for distributing security notices. True, there is an openwrt-security-announce list, but it appears to be entirely unused, as is openwrt-announce. Something to keep an eye on, then. Also (file under note to self), I need to remember to verify that the router isn't exposing services to the outside world. The default iptables configuration is hideously complex; with just a quick glance, it could be setting up a floral shop for all I can tell. I'll need to test this empirically and maybe analyze the rules in more depth.

In case you want to buy some (more) bottles of wine made for DebConf9, you need to hurry up. Also a bit more hurry is appropriate if you want it to be delivered til XMas :-)



(Picture credit belongs to Chris.)

I'm planing another (offline) sale at the 26C3 congress in Berlin at the end of the year, which might or might not work out. If it does, the number of bottles available for online ordering will be reduced significantly, and basically I'm only waiting for some details to be finalized for announcing this for real, so hurry up and mail order now - unless you have enough Debian wine bottles at home already :-)

Information how to order is available in our wiki at DebianWine. The profit made will be given to DebConf9, and as that has been dealt with finacially successfully, it will be given to DebConf10!

Debian 5.0.2 wine, which was made to support DebConf9, is finally available to be bought on the internetz. Currently the shop user interface is German language only, but I've heard that this will be fixed eventually.

Enjoy!

A few speakers at DebConf8 used gobby during their talks to collate ideas without breaking the flow of the session.
I've just come back from the Emdebian meeting in Extremadura (of which more later) where we also used Gobby - FAI used it too. Once the network setup was working, it was simply a case of clicking Create Session in gobby on my laptop and everyone else clicking Join Session, entering the IP of my laptop (only accessible locally) and choosing a colour.
Gobby is real-time, currently plain-text only but clearly indicates how sections have been edited and has an integrated IRC box for each session. At the end of the meeting, every gobby user has a copy of every document they opened in every session they joined. updated to the moment they quit the session.
Based on using gobby in events like this, I'd strongly recommend that someone at each worksession-type meeting starts a gobby session and maintains that session for the duration of the meeting.
Gobby even does syntax highlighting - depending on how many people join and the colours they choose, this might become difficult so it can be turned off too.
There are only a few minor issues:

1. The colour bar warning box isn't particularly intuitive - you need to click on what looks like a dimmed progress bar to select a unique colour for yourself.


2. I initially thought that Gobby had no authentication - in a local meeting, anyone who can connect to the specified IP address is able to edit the document. Since then, I've noticed it does support password authentication and there is mention of fully encrypted connections so it may be possible to use it over public networks.


3. According to Wikipedia, there is a gobby server that allows non-GNU/Linux clients to run gobby and join any gobby session - I didn't explore this and the Debian package doesn't mention anything about a server option or mixed-OS support.
   
   • Update - the server is called Sobby and is in Debian.
   
   


4. The right hand side of the window is a bit wasted - maybe some kind of sidebar would be handy, especially docking the userlist into the window so that edits can be identified more quickly.

Sick of a ridiculous pile of tiny bottles falling everywhere in your cupboard? Many people will sell you many expensive solutions. However, I think we've hit on something cheap, effective and practical; zip-lock bags in a deep tub, labelled with sticky tags.  

• Easy to find.
• Easy to get any sized spoon into the bags, or for tipping if you just open a corner.
• For freshness, you can vaccuum seal with a straw a-la Alton Brown.
• Buy the cheap spices in bulk and pay significantly less.
• The more expensive bags with two rows of sealing are a little easier to close, if they come in a good size for your container.
• Label with the date if you know it.

I recently picked up the Netgear WG311 V3 very cheap from Office Depot. The card seems to work fine with ndiswrapper; there are other guides on getting it working. The first problem was the reception was, in a word, rubbish. After putting the box back in it's usual home the house wireless was lucky to get a 7/100 signal rating. I found a work-around while the cheap external antenna I ordered is arriving; shield the antenna with foil. This increased signal to between 30-40/100, a considerable boost making it actually useful. The second problem was coming to terms with wpa_supplicant, of which the details often become very confusing very quickly. Here's the Debian 2-second guide for a simple, standard WPA network I was looking for:

1. Add to /etc/network/interfaces

   iface wlan0 inet dhcp
   # Useful with ifup -v 
   #    wpa-debug-level 3
        wpa-conf /etc/wpa_supplicant.conf
   

2. /etc/wpa_supplicant.conf should look like:

   network= 
           ssid="your_ssid"
           psk="your_password"
           key_mgmt=WPA-PSK
           proto=WPA
    
   

I’m the happy owner of a Linksys WRT54GL. OpenWRT is nice, but … well. Debian is just nicer. And I couldn’t resist the idea of running Debian on this little MIPS system. Since there’s clearly not enough space available on the Linksys, I decided to install etch in a chroot, that I would mount using NFS. Joey tried that already, the Debian wiki provides some information, but I use another technique. First, on another system (an i386, I debootstrap’ed a mipsel etch, using –foreign. This tells debootstrap not to run the second stage:
debootstrap –arch mipsel –foreign etch /space/debian-mipsel http://ftp.fr.debian.org/debian Then, I modified /etc/exports to allow the router to mount that chroot:
/space/debian-mipsel 192.168.1.1(rw,sync,no_root_squash) I mounted it on the router:
ipkg install kmod-nfs
insmod sunrpc
insmod lockd
insmod nfs
mount -t nfs star:/space/debian-mipsel /debian -o nolock
mount -t proc /dev/null /debian/proc I set up some swap space on the NFS mount (mandatory, or debootstrap’s second stage will fail):
ipkg install losetup
ipkg install kmod-loop
ipkg install swap-utils
dd if=/dev/zero of=/debian/swapfile bs=1M count=100
losetup /dev/loop/0 /debian/swapfile
mkswap /dev/loop/0
swapon /dev/loop/0 I chrooted inside /debian, and ran debootstrap’s second stage:
chroot /debian /bin/bash
debootstrap/debootstrap –second-stage When you are done playing, you can disable the swap space and umount everything:
swapoff /dev/loop/0
losetup -d /dev/loop/0
umount /debian/proc
sleep 1 # or umount /debian will fail
umount /debian If you want to re-mount everything, all you need to do is:
insmod sunrpc
insmod lockd
insmod nfs
mount -t nfs star:/space/debian-mipsel /debian -o nolock
mount -t proc /dev/null /debian/proc
losetup /dev/loop/0 /debian/swapfile
swapon /dev/loop/0
chroot /debian /bin/bash That first stage/second stage split in debootstrap is really cool: it’s an easy way to run Debian anywhere, only requiring to be able to chroot at some point.

Came yesterday (thanks Hanna and Steve!). And yes, I am much too lazy to fix the red eye right now as I’m on my way out the door. I finally have some geeky Debian bling to show off to the unconverted. Bwaha.